home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Apr 89 / T0014-Re Dangerous lock i-Apr89 < prev    next >
Encoding:
Text File  |  1989-04-13  |  3.6 KB  |  78 lines  |  [TEXT/GEOL]
  1. Item    6829672                         12-April-89        15:16
  2.  
  3. From:   ALGER                           Alger, Jeff
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. cc:     FRIEDRICH1                      Friedrich, Steve
  8.  
  9. Sub:    Re: Dangerous lock in 2.0ß7
  10.  
  11. I agree wholeheartedly with Paul Smith on this one: lock counts are the "right"
  12. way to handle object locking.  My reasons (not an exhaustive list) are as
  13. follows:
  14.  
  15. • Semaphores are the tried and true mechanism for resource control in more
  16. traditional environments.  I find no compelling reason to reinvent the concept
  17. in MacApp.  Arguments of "overhead" fall flat with me: in a MacApp application
  18. a couple of bytes per object is a raindrop in a thunderstorm.  Even if one
  19. objects to storing the reference count in each object (I certainly do not), the
  20. literature is full of techniques for efficiently maintaining the locks
  21. externally.
  22.  
  23. • Use of a reference counter does not require keeping track of local variables
  24. to remember the state.
  25.  
  26. • Having object A remember the prior state of object B somewhat goes against
  27. the grain of object-oriented programming.
  28.  
  29. • On a purely subjective, personal note, I have used both techniques in the
  30. past and have found lock counts to be much easier to deal with.
  31.  
  32. I might suggest two additional methods to add to Paul's list which facilitate
  33. error handlers:
  34.  
  35. Function TObject.LockCount: Integer;   { return the current lock count }
  36. Procedure TObject.ResetLockCount (newCount: Integer);   { set lock count to
  37.     newCount unconditionally }
  38.  
  39. These are only to be used when there is a special requirement to restore state,
  40. such as with an error handler, and they are admittedly grubby.  Does this
  41. really reduce to the technique used in 2.0ß9?  Yes, but ONLY when you have a
  42. real need to remember state; in all other cases, you need not worry about the
  43. details.  The best of both worlds!
  44.  
  45. While the waters are boiling, I would like to humbly suggest an analogous
  46. extension to TObject which is simple to implement and tremendously useful: a
  47. "reference count" which is distinct from a lock count.  When you have a class,
  48. each instance of which may be pointed at from a variety of places, there is
  49. always a big problem in freeing the instance exactly once and only after all
  50. references to it have been invalidated.  By implementing two primitives, one
  51. can implement self-owned objects:
  52.  
  53. Procedure TObject.Grab;   { call whenever you store an object's handle }
  54. Procedure TObject.Release;{ call whenever you stop storing an object's handle}
  55.  
  56. Grab increments the reference counter by one, while Release decrements it and,
  57. when it reaches zero, calls TObject.Free.  This is benign in cases where Grab
  58. and Release are never called, so it may be used when appropriate.  It also
  59. works well with inheritance insofar as Release may be overridden to do special
  60. cleanup first, then call Inherited Release or not as the situation dictates.
  61. Among the many benefits of this is the ability to breakpoint on these methods
  62. to watch the usage of an instance as a program runs!  Another consequence is
  63. that Free can make sure its reference count is zero before continuing, thereby
  64. making sure that dangling references will not continue to point to an object
  65. after it has been freed.
  66.  
  67. We have used this scheme with great success for particular classes and wish it
  68. were in TObject.  In fact, we have taken the concept one step further by
  69. passing a "byWhom" argument to Grab and Release which is used in debug mode to
  70. maintain a list of objects which reference the one Grabbed.  From the Inspector
  71. one can instantly see every object which references a given one at any time.
  72.  
  73. Any comments?
  74.  
  75. Jeff Alger
  76.  
  77.  
  78.